1. Field of the Invention
The invention relates to a method and apparatus for updating application databases in real time in a distributed transaction processing environment without adversely affecting the throughput of transaction processing or losing substantially any conversational transactions that are being processed while these databases are being updated.
2. Description of the Prior Art
Distributed real time transaction processing is currently finding increasing use as a method of implementing sophisticated high throughput application processing to provide local control over a process that occurs over a wide geographic territory and/or to serve many users who are dispersed over such a territory.
One form of distributed processing involves locating a processing element at each one of a number of local control points within the process being controlled and then permitting each such processing element to query, as the need arises, one or more databases, on a transactional basis, that are managed by and situated at a remotely located host computer in order to obtain additional information that is necessary for that local processor to provide its intended control function. This form of distributed processing is particularly suitable for controlling a telephone switching network to provide enhanced telephone services. In this regard, each local processor forms part of an equal access switch that has service switching point capability (such a switch will henceforth be referred to as an "SSP").
Specifically, whenever a telephone subscriber dials a telephone call that requires special routing, as in the case of an enhanced service such as illustratively "800" or calling card ("credit") type calls, a local switch that serves that subscriber first routes the call to the SSP. The SSP, in turn, suspends normal call processing for this call and launches a query as a packet over a common channel signaling ("CCS") network to a remotely located fault tolerant transaction processing system, hereinafter referred to as the service control point ("SCP"), that stores pre-defined call routing instructions for the desired enhanced service. In the case of an "800" type call, this information contains the called number. In response to the information contained within the query, the SCP performs a remote database translation operation into one or more databases of customer records for "800" service in order to fabricate a response that specifies how the call is to be ultimately routed, which in this case consists of a response that specifies an inter-exchange carrier and a pre-defined physical destination number that are both associated with the dialed "800" number. The SCP then embeds this routing information into a response message and thereafter transmits this response message as a packet back through the CCS network to the SSP that requested the information. Upon receipt of this response message, the SSP routes the call through the telephone network accordingly.
Depending upon the sophistication of the control being provided, distributed transactional processing systems may involve, in order of complexity, both query-response type transactions and/or conversational transactions.
In simple query-response type transactions, typified by those that occur in conjunction with "800" type call processing as explained above, a transaction merely consists of a query that has been transmitted by an SSP to an SCP and an associated response generated thereby and returned to that SSP. Inasmuch as the query contains sufficient input information to enable a remote database management system executing within the SCP to undertake a database translation operation and provide a complete response, the SCP requires no further information from either the SSP or therethrough the caller to provide the routing instructions needed to complete an "800" type call. Similar query-response type transactional processing occurs between an SSP and an SCP in processing credit card calls where the response message, rather than being a carrier selection and a physical destination routing number, consists of an instruction to the SSP to either route or terminate the call. Query-response type transaction processing also occurs in a variety of other relatively unsophisticated distributed processing applications, such as retail credit authorization and simple inventory control systems.
In instances where increasingly sophisticated control is desired, such as in controlling a telephone network to provide private virtual network ("PVN") or other such services, a customer record contains a decision tree rather than simple data values, such as carrier selection and physical routing numbers. The decision tree allows a processing system, e.g. the SCP, to interrogate the caller and, as determined by the information obtained therefrom and the logic specified within the tree, provide proper call routing information to furnish the specific service requested by the caller, e.g. provide a connection to a certain extension defined within a PVN. with such services, a query itself frequently does not contain sufficient information to enable the SCP to fully process through the decision tree. As such, the SCP conducts an interactive session with the caller to successively obtain whatever additional items of information the customer record specifies are needed to fully process the call and render a desired service. In particular, for such a service, the caller generally dials an appropriate telephone number to gain access to the desired service, e.g. a specific PVN. Once this occurs, the SSP associated with this caller fabricates a query to gain access to the service for that caller, then generates a packet containing the query and thereafter routes that packet over the CCS network to the SCP that handles the desired service. The SCP then performs a database access into a customer record to determine the next piece of needed information, e.g. a personal identification number PIN) and authorization code, that has to be obtained from the caller. Once this occurs, the SCP requests this piece of additional information by in effect questioning the caller. To do this, the SCP inserts an appropriate op code within a transaction capability application part (TCAP) message, and then transmits this message within a packet via the CCS network back to the SSP. In response to this op code, the SSP synthesizes a pre-defined voice message to prompt the caller to enter, by for example dialing digits on a telephone keypad, the desired Piece of additional information. Once the caller provides an answer, it is transmitted as a TCAP message within another packet by the SSP back to the SCP that requested it. In response to the answer, the SCP then re-accesses the customer record in order to determine the next piece of information it needs from the caller, and so on. Inasmuch as the nature of each additional piece of information often varies in response to the previous answer, the question and answer session occurring between the caller and the SCP is carried out on an interactive basis. Each question and answer session, henceforth referred to as a conversation with each TCAP message that carries part of the conversation being referred to as a conversational message, continues until the SCP has successively collected enough information from the caller via the SSP, as defined by the customer record, to fully process the customer record and by so doing determine how the call is to be routed. Once this occurs, the SCP sends a response message containing destination routing information as a packet back to the SSP which, in turn, routes the call accordingly. At this point the SCP has fully processed the transaction. As such, a conversational based transaction can be viewed as "Query--Conversation--. . . --Conversation--Response". Conversational type transaction processing may also occur in a variety of other relatively sophisticated applications, such as illustratively space reservation systems and factory automation and/or computer integrated manufacturing systems.
Essentially all computer databases need to be updated from time to time. This is particularly true for distributed processing systems that provide transactional processing using customer records, whether those records support query-response type transaction processing or conversational processing. For example, each customer record for PVN service contains data that defines the particular manner in which a customer's virtual telephone network is to act. By changing a customer record for PVN service, a customer has the option to change this network by adding or deleting extensions, to change the manner in which calls to existing extensions are to be handled, to specify within certain bounds what administrative data is to be collected for calls routed over this network or to make other changes that affect various features that can be selectively provided by the PVN service. Customer records that implement other types of enhanced telephone services, such as "800" and credit card type calls, that rely on remote database translation are also frequently changed as well. Inasmuch as customer records continually change as new service features are offered and are subscribed thereto or existing features that are no longer desired by individual subscriber(s) are deleted therefrom, the application databases that support each enhanced service undergoes constant change. It is therefore incumbent upon local telephone companies to always utilize the most recent version of the application databases within the SCP and to frequently update these databases in order to provide the proper enhanced services to their subscribers.
Traditionally, whenever an application database update needs to be performed in many data processing environments, an associated application program is merely terminated, the database is then updated and thereafter the application program is finally returned to current execution using the updated database, with this approach, the application program simply ceases to execute for whatever period of time is needed for the processing system to perform the update. In this regard, see E. A. Davis et al "Life Cycle Support and Update of No. 4ESS Software", IEEE International Conference on Communications. ICC'82. The Digital Revolution, 13-17 June 1982. Philadelphia, Pa. Vol. 13, pages 5G5.1-5G5.6 which discloses a similar technique for updating generic programs that control an electronic switching system. Unfortunately, when a generic program in a switch is to be updated in this manner, some traffic loss is likely to occur. Accordingly, to minimize the risk of any service disruption resulting from use of this technique, any such update would typically be accomplished during those times of the day when the traffic is expected to be the least and all traffic to the switch would be throttled back immediately before an update is to occur.
However, to assure that adequate on-line call processing capacity exists to handle unexpected peaks in transactional processing, e.g. call traffic for enhanced services, many distributed processing systems, and particularly those that process calls for enhanced telephone services on a high throughput transactional basis, should preferably remain on-line while their application databases are being updated. Although distributed processing systems, particularly those destined to control telephone networks to provide enhanced services, frequently contain redundant host processing systems, i.e. two loosely inter-connected SCPs with automatic mate switching to transfer call processing therebetween and replicated loosely coupled back-end processors within each SCP (as disclosed in detail in Boese et al United States patent application, "A REAL-TIME FAULT TOLERANT TRANSACTION PROCESSING SYSTEM", filed Nov. 25, 1987, assigned U.S. patent Ser. No. 07/125,463 and currently owned by the present assignee, now U.S. Pat. No. 5,084,816, issued Jan. 28, 1992 and also disclosed to a much lesser extent in J. O. Boese et al, "Service control point--Database for 800 Service", Conference Record of Globecon '86: IEEE Global Telecommunications Conference December 1-4, 1986 Houston, Tex., Vol. 3, December 1986, pages 1316-1319), the removal of an entire processing system, i.e. an SCP, from service disadvantageously decreases the call processing capacity of the network during the time updating is occurring. Inasmuch as an unexpected peak in call traffic could occur while an update is occurring, the SCP should remain on-line with updating being performed on a real time basis in order to provide sufficient reserve call processing capacity to handle any such peak.
Although various well-known techniques exist for updating application databases in a distributed processing environment on a real-time basis, i.e. without halting on-going application processing, these techniques possess one or more drawbacks that limit or even negate their utility for use in updating application databases on a real-time basis that are used in providing enhanced telephone services.
In particular, one well-known updating technique for use with a distributed processing system employing loosely coupled processors having separate databases is disclosed in U.S. Pat. No. 4,718,002 (issued to R. W. Carr on Jan. 5, 1988). This technique first prioritizes the processors into a given order and establishes one of the processors as a control processor. Whenever one of the processors has developed an update message, the control processor instructs that one processor to broadcast the update message to all the other processors. In the event the control processor fails, then the next processor in order is selected to be the control processor. Unfortunately, this technique is rather complex to implement.
Another technique exists that could be used for updating application databases within an SCP that contains replicated back-end processors. This technique involves successively taking down each individual back-end processor in the SCP, creating a new version of each application database on the "down" back-end processor, then directing that back-end processor to immediately process transactions through the new application databases and thereafter returning that back-end processor to service. Once this occurs, the old versions of these databases are merely deleted from storage. In effect, this technique simply substitutes, on a nearly instantaneous basis, a new version of each application database for a corresponding old version thereof. Unfortunately, this technique while being quite simple has a significant drawback associated with its use: merely substituting one version of an application database for another in any back-end processor and thereafter immediately directing that processor to only use the new version may cause the SCP to prematurely terminate transaction processing for a number of on-going conversational transactions and thereby lose traffic. In particular, an SCP utilizes an architecture having loosely coupled replicated back-end processors that all access a common shared disk farm that stores the application databases for each of these processors. With this arrangement, different conversational messages that collectively form a given conversational transaction are typically routed to different back-end processors that provide incremental processing for that transaction. In order to effectively implement conversational transaction processing with this architecture, each processor that is to provide any such incremental processing utilizes a transaction identifier field embedded within each conversational message to access a specific entry in a context file within the application database(s) associated with a particular back-end processor that initiated the entire processing of that transaction. This technique is fully described in my prior United States patent application "A METHOD FOR HANDLING CONVERSATIONAL TRANSACTIONS IN A DISTRIBUTED PROCESSING ENVIRONMENT", filed Aug. 8, 1988, assigned U.S. patent Ser. No. 229,241 and currently owned by the present assignee, now U.S. Pat. No. 5,089,954 issued Feb. 18, 1992. Now, owing to the inclusion of new features in an given service, an updated application database may be configured in a significantly different format than the old version thereof. Therefore, the newly updated application database that would be accessed by a back-end processor in the SCP may be incompatible with the old version of the same database that would otherwise, in the absence of being updated, be accessed by that processor. Consequently, if a conversational transaction is being processed within an SCP using the old version of the application database and then an update occurs causing the remainder of the processing of that transaction to be performed using the newly updated version of that database, then, due to incompatibility between the versions, the SCP will likely be unable to process the next or a subsequent conversational message in that transaction and will accordingly drop the entire transaction thereby disadvantageously terminating the call.
Thus, a need exists in the art for a method for updating application databases in real-time in a distributed transaction processing system that is simple to implement, does not appreciably adversely affect the throughput of conversational transaction processing and does not cause substantially any loss of transactions while updating is occurring. Such a method would advantageously find use within a distributed processing system that controls a telephone signaling network to provide sophisticated enhanced services and specifically within an SCP used in such a network which employs an architecture of loosely coupled replicated back-end processors that all access application databases residing on a common shared disk farm and which provides these enhanced telephone services through conversational transaction processing.